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BACKGROUND OF THE INVENTION 

Today, portable consumer electronic devices are more powerful than ever. 

For example, small, portable music playback devices can store hundreds, even thousands, of 
1 5 compressed songs and can play back the songs at high quality. With the capacity for so many 
songs, a playback device can store many songs from different albums, artists, styles of music, 
etc. 

Music jukeboxes implemented in software executed by a digital computer and 
portable MP3 and CD players both provide facilities for forming playlists. For example, the 
20 OOZIC player, distributed by the assignee of the present application, runs on a host PC and 
has a play list feature that allows selection of tracks from the PC's hard disk to be included in 
the playlist. 

As storage capacity increases and songs are compressed to shorter file lengths 
the number of songs that can be stored increases rapidly. Major problems facing the 
25 consumer are organizing and accessing the tracks. 

Typically, portable devices have a user interface including a small screen and 
buttons. Using such a compact user interface to navigate and select among hundreds of songs 
is inefficient and often frustrating. The display screen can only show a few song titles at one 
time, and the limited controls make it difficult for a user to arbitrarily select, or move among, 
30 the songs. 

The creation of playlists is one technique to organize the playing of songs. A 
set of songs can be included in a playlist which is given a name and stored. When the playlist 
is accessed, the set of songs can be played utilizing various formats such as sequential play or 
shuffle. 



However, the creation of playlists itself becomes problematic as the number of 
songs increases, since the user often arbitrarily selects songs from a large number of tracks to 
form a playlist. This selection mechanism: can be fairly tedious; does not necessarily 
produce playlists that are of interest to the user over the course of time; may not remain 
5 up-to-date if new songs are added that logically fit into a previously created playlist (e.g. 
"Favorites by Band X" might become out of date if a new favorite by Band X is added after 
the playlist was created); and leads to "lost" songs that are not members of any playlist. 

Accordingly, improved techniques for organizing and grouping tracks useful 
in a portable music player are needed. 
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SUMMARY OF THE INVENTION 

According to one aspect of the present invention, a technique is provided for 

organizing tracks on a portable music player by automatically filing tracks in a hierarchical 
1 5 order based on attributes of the tracks. 

According to another aspect of the invention, metadata is associated with each 
track that is used to automatically define the track's appropriate place in the hierarchy. 

According to another aspect of the invention, the hierarchy is displayed on the 
portable music player so that a user can traverse the organizational hierarchy to find 
20 individual tracks or find playlists composed of logical groups of tracks. 

According to another aspect of the invention, the hierarchy is derived by using 
metadata associated with the audio content that was obtained through any source of metadata 
(e.g. CDDB metadata, id3v2 metadata, other obtainable metadata) and subsequently stored 
with or alongside the file that stores the track. 
25 According to another aspect of the invention, a file is formatted so that an 

unaltered track is stored as file data and information about the track is stored in file attribute 
files. 

Other features and advantages of the invention will be apparent in view of the 
following detailed description and appended drawings. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

Fig. 1 is a schematic diagram of a tree structure for hierarchical filing of 

tracks; 



2 



Fig. 2 is a definition file that specifies the hierarchy depicted in Fig. 1; 
Fig. 3 is a user's view of the hierarchy; 

Fig. 4 is a schematic diagram of a user interface displaying the hierarchical 
category structure; 

5 Fig. 5 is a diagram of a file format for storing filed data and file attributes; 

Fig. 6 is a flow chart depicting steps for filing tracks according to the 
hierarchical tree structure; 

Fig. 7 depicts a tree resulting from searching the tracks; and 
Fig. 8 depicts a format for a user interface. 



DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

A preferred embodiment of the invention will now be described in the context 

of a portable personal player that plays audio files stored in memory. The files may be in 

1 5 MP3, wav. or other digital formats. 

In the presently described embodiment, users are able to see the tracks on their 
player in some organized fashion other than as a single list of tracks. As will be described in 
more detail below, in one embodiment tracks are sorted utilizing a tree structure having 
branches labeled according to types of metadata associated with the tracks 

20 For example, a track recorded as "Golden Slumbers" by the Beatles that 

appears on their album "Hey Jude" might appear as a track under the album "Abbey Road" as 
well as a track under the list of tracks by the Beatles. It might appear as a track under the 
genre "Pop Rock" as well as "Songs from the 60's." Furthermore, the organization can have 
more complex hierarchies. For example, the category of "Pop Rock" might contain 

25 subcategories "British Musicians," "American Musicians" and "Other Musicians". In all 
cases, the track is automatically filed into all appropriate locations without requiring user 
interaction. 

In the currently defined embodiment, a tree structure is defined by a file 
having the following structure. 
30 The first line of a TreeDef.inf file contains a version number: 

V1.0 

Each subsequent line (at least in vl.O) contains lines of the following format: 
CATEGORY_NAME|TRACK_TYPE MASK|CATEGORY_STRUCTURE 
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CATEGORY_NAMEs are the top-level names of the branch under which 
tracks are sorted. They include things like "Album," "Artist," "Voice Tracks," "All Tracks," 
etc. 

TRACK_TYPE_MASKs tell which types of tracks are to be filed under this 
5 particular branch. The actual value is a hexadecimal numerical value (in 'Ox' format, e.g. 
0x01) generated by ORing the following flags together as appropriate: 

enum tTrackType 
{ 

10 kTTNothing=0x00, 

kTTSong=0x01, 

kTTVoice=0x02, 

kTTBook=0x04, 

kTTMacro=0x08, 
15 kTTPlaylist=0xl0 

}; 

So, for example, the "Album" branch has a TRACK_TYPE_MASK of 
kTTSong, because only songs are filed under that branch, but the "All Tracks" branch has a 
20 TRACKTYPEJVIASK of (kTTSong | kTTVoice | kTTBook). 

Other elements might be added to tTrackType (e.g. kTTVideo) as appropriate. 
CATEGORYSTRUCTUREs tell how to file the songs based on their 
metadata information. The CATEGORYSTRUCTURE is a string of characters that tell, 
from left to right, the order of hierarchy. The characters come from the following enum 
25 constants: 

enum tFileTag 
{ 

kFTNone='@', 
30 kFTTrackType='T, 
kFTTitle='N', 
kFTAudioFile='F', 
kFTArtist='M', 
kFTAlbum-L', 
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kFTGenre='G\ 
kFTSource='S', 
kFTYear='Y', 
kFT ArtistCountry= ' C ' 

5 }; 

Thus, a CATEGORYSTRUCTURE of LN tells to create a subcategory that 
is a list of Albums, each of which contains a list of Tracks. 

In total, a line like: 
10 Album|0x01|LN 

Says to create a branch called "Album" which contains tracks of type 
kTTSong organized first by album name, and then by track name. 

The following is an example of a tree definition file similar (though not 
identical) to the hierarchy presented in the Nomad Jukebox product (the 'B' before each 
1 5 FileTag was used to identify that these are basic tags so that we wouldn't run out of letters in 
the alphabet as we included more complex metadata - thus each group of two letters 
represents a level in the hierarchy): 

V1.0 

20 Album|0x01|BLBN 

Artist|0x01|BMBN 

Genre|0x0 1 |BGBN 

Voice Tracks|0x02|BSBGBN 

Playlists|0xl0|BN 
25 Macros|0x08|BN 

All Tracks|0x07|BN 

Fig. 1 depicts a hypothetical organization hierarchy. The tree shows how 
tracks might be listed (as leaves in the tree) after having been organized. Example values for 
30 nodes in the tree are shown as well. The same track may appear more than once as a leaf in 
the tree, as described above, if it fits into multiple categories (e.g. a song that appears on the 
Abbey Road branch would also appear in the Beatles branch). In the example shown, the 
first branch contains tracks organized by album. As shown in the example, this music 
collection contains three tracks from "Abbey Road" and three tracks from "Hits from the 
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60's". The second branch contains tracks organized by artist, and sub organized by where the 
artist is from. Thus, a user browsing would first select the "Artists" branch and then choose 
between "British Artists" and "American Artists". Finally, they would select the particular 
artist. In the third branch, all tracks are shown. 
5 The tree definition file that would specify the hierarchy shown in Figure 1 is 

shown in Figure 2. 

The first line identifies the version of the tree definition file. 

The second line defines the "Albums" branch. The first part of the line, 
"Albums" defines the name of the branch. The second part, "0x01," defines that all musical 
10 tracks should be categorized on this branch. The third part, "BLBN," defines that the branch 
lists first the names of all albums (BL) and then tracks on those albums (BN). 

The third line defines the "Artists" branch. The first part of the line "Artists" 
defines the name of the branch. The second part, "0x01 ," defines that all musical tracks 
should be categorized on this branch. The third part, "BCBMBN," defines that the branch 
1 5 lists first the names of all countries where artists in this collection come from (BC) and under 
those items, the artists' names (BM), and then tracks by those artists (BN). 

Fig. 3 shows what a user's view of this hierarchy might be if he/she were 
shown a fully expanded view of the 6-song tree. Notice that each song appears three times, 
once in each branch. 

20 In consumer products the tree define file is not edited directly but through a 

user interface, one example of which is depicted in Fig. 4. An example of a user interface for 
viewing songs by category and editing the tree structure is depicted in Fig. 4. 

An embodiment of the invention is utilized in the Nomad® Jukebox, 
manufactured by the assignee of the present invention, and described more fully in the 

25 copending application, filed on the same date as the present application, entitled "System for 
Selecting and Playing Songs in a Playback Device with a Limited User Interface," (Attny. 
Docket No. 17002-020800). 

In a preferred embodiment, metadata is associated with each track and 
includes such information as title, genre, artist name, type, etc. In the preferred embodiment, 

30 software stored in a portable player and executed by the onboard processor automatically 
files each track in the correct category utilizing the associated metadata and the tree define 
file. The program code can be stored in any computer readable medium including magnetic 
storage, CD ROM, optical media, or digital data encoded on an electromagnetic signal. 
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Thus, the user is automatically provided with a powerful and flexible tool for 
organizing and categorizing the tracks stored on the portable player. 

If the tracks are formatted in MP3 format the metadata can be stored in ID3 
tags included in the MP3 file. In one embodiment of the invention, the tracks are stored in 
5 alternate file format including file data and file attributes. The file data is the music track 
itself and the file attributes part of the file includes fields of arbitrary size which are used to 
store metadata characterizing the track stored as the file data. Again this metadata includes 
information about the track such as title, genre, artist name, type, etc. 

There are several advantages to using the alternate file format. Metadata of 
1 0 types not easily included in an ID3 tag can be utilized. Further, the original track format is 
not changed, so that error correction data such as checksums are valid. Finally, any file 
format can be used (e.g. WAV, WMA, etc.) because the metadata is stored separately, and 
thus audio formats that have limited support for metadata can still be stored on the portable 
player in native format without transcoding. The formatted files are formed by software 
1 5 stored in the portable music player and executed by an on-board processor. 

The metadata for each track is utilized to file each track, using the categories 
defined in the hierarchical structure as described above, without any input from the user. 

Fig. 5 is a schematic diagram of the alternative file format including file data 
in the form of an MP3 track, and metadata fields for holding data indicating the name of the 
20 album the track is from, the name of the song, the genre of the song, and the type of track. 

A particular embodiment of a file format will now be described. All tracks are 
created with some set of attributes as shown below: 



Definition of Tracklnfo Data Field 



Field 


Offset 


Size 


Description 


Attribute Count 


0 


2 


The number of attribute follow for the track 


Attr 1 type 


2 


2 


Binary = 0, ASCII = 1 


Attr 1 name len 


4 


2 


Length of attribute name string 


Attrl data len 


6 


4 


Length of attribute data 


Attrl Name 


10 


N 


Attribute name string 


Attr 1 Data 


10+N 


M 


Attribute data 
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Attr N type 








Attr 1 name len 








Attrl data len 








Attrl Name 








Attr 1 Data 









Required Attributes 



Attribute Name 


Value(s) 


Remarks 


TITLE 


ASCII string 


Reauired Bv Jukebox 


CODEC 


"MP3", "WMA", "WAV" 


Required Bv Jukebox 


TRACK ID 


DWORD 


Set By Jukebox 


ALBUM 


ASCII string 


Optional 


ARTIST 


ASCII string 


Optional 


GENRE 


ASCII string 


Optional 


LENGTH 


In seconds 


Optional 


TRACK SIZE 


In bytes 


Optional 


TRACK NUM 


1-n (track within album) 


Optional 



These attributes can be subsequently changeable via a host application, 
5 running on a personal computer connected to the portable music player. 

Fig. 6 shows a flow chart of an embodiment the process used to build the 
hierarchical database of tracks. It starts by iterating through each track, and, for each track, 
iterating through each branch to find if the track belongs on the branch, and, if so, where. In 
this case, the term track could refer to any content, e.g. a music track, a spoken word track, or 
10 even a video track. 
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Also, the hierarchical catalog of tracks can be used to form playlists in a 
structured manner. For example, if a user wants to hear Jazz and Blues the entire sub- 
categories can be selected to form one playlist. 

An alternative hierarchical catalog generation technique will now be 
5 described. In this alternative embodiment, at system startup and as tracks are added or 
changed, the hierarchy is generated as an in-memory tree structure. Each track is added to 
the tree using the categories ALBUM, ARTIST and GENRE. 

The following example shows the algorithm for adding a track. For clarity, 
only the attributes used by the tree are shown. 
10 



TITLE 


"Free Falling" 


ALBUM 


"Full Moon Fever" 


ARTIST 


"Tom Petty" 


GENRE 


"Rock" 


TRACK NUM 


1 



The following function is executed to build the in-memory memory tree. 

Build Tree () 
1 5 For each track, 

Add Track To Category(Album, Track) 

Add Track To Category( Artist, Track) 

Add Track To Category(Genre,Track) 
End of Build Tree 

20 

Fig. 7 depicts a tree which could result from implementing Build Tree() 
function. Note that "Stardust" does not have any entries for Album or Artist. The host 
software running on a computer connected to the portable music player could be utilized to 
add missing attributes to the "Stardust" track and, optionally, edit the title attribute. The 
25 Build Tree() function would then reinsert this track in the correct location in the tree. 

Fig. 8 is an embodiment of a user interface according to another embodiment 
of the invention. In this example the root node is labeled "My Configuration" and the 
Playlist category has been selected and the Playlist subcategory "Meddle" has been selected. 
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Note that the types of Metadata, in this example, Track Name, Artist, Album, Tempo and 
Dance, are listed across the top of the screen, and the attribute values for each track are listed 
in a row across the screen. Various control buttons are displayed to the right of configuration 
window that facilitate quickly invoking selected processing on a selected track. 

The invention has now been described with reference to the preferred 
embodiments. Alternatives and substitutions will now be apparent to persons of skill in the 
art. 
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